lililllllllllllillllllllllllilllllilllllllll 

US006675230B1 

(12) United States Patent (lo) Patent No.: us 6,675,230 Bl 

Lewaiien (45) Date of Patent: Jan. 6, 2004 



(54) METHOD, SYSTEM, AND PROGRAM FOR 
EMBEDDING A USER INTERFACE OBJECT 
IN ANOTHER USER INTERFACE OBJECT 

(75) Inventor: Stephen Richard Lewaiien, San Jose, 
CA (US) 

(73) Assignee: International Business Machines 
Corporation, Armonk, NY (US) 

( * ) Notice: Subject to any disclaimer, the term of this 
patent is extended or adjusted under 35 
U.S.C. 154(b) by 617 days. 

(21) Appl. No,: 09/643,292 

(22) Filed: Aug. 22, 2000 

(51) Int. Ci.^ G06F 15/16 

(52) U.S. CI 709/328; 345/744; 345/762; 

709/329 

(58) Field of Search 709/320, 321, 

709/322, 323, 324, 328, 329; 345/744, 
762; 707/102 

(56) References Cited 

U.S. PATENT DOCUMENTS 
6,016,392 A 1/2000 Jordan 

6,061,695 A * 5/2000 Slivka et al 715/513 

6,469,714 B2 * 10/2002 Buxton et al 345y762 

6,522,343 B2 * 2/2003 Sobeski et al 345/744 

OTHER PUBLICATIONS 

User Interface Software Tools, Brad A. Myers, Carnegie 
Mellon University, ACM Transactions on Computer-Hu- 
man Interaction, vol. 2, No. 1, Man 1995, pp. 64-103.* 
An Overview of Portable GUO Software, SIGCHI Bulletin, 
vol. 27, No. 1, Jan. 1995.* 

Anatomy of a Compact User Interface Development Tool, 
Communications of the ACM, Jan. 1988, Volum 31, No. 1.* 
Creating Host Compliance in a Portable Framework: Astudy 
in the Reuse of Design Patterns, Phillip M. Yelland, 1996 
ACM 0-89791-788-X/9610010.* 



Microsoft Corporation, "The Component Object Model 
Specification", Version 0.9, Oct. 24, 1995. 

J. Robie, "What is the Document Object Model?", Texcel 
Research, REC-DOM-UvcI-1-1 9981001, pp. 1.5, [re- 
trieved on Feb. 7, 2001]. Retrieved from the Internet <URL: 
http://www.w3.org/TR/REC-DOM-Lcvel-l/introduc- 
tion.html>. 

C. Verbowski, "Integrating Java and COM", Microsoft, 
Corporation, Jan. 1999, pp. 1-10. 

Microsoft Corp., "Document Object Model Overview", 
copyright 2000, pp. 1-10, [retrieved on Feb. 6, 2001]. 
Retrieved from the Internet <URL: http://www.microsoft- 
.com>. 

IBM Corp., "SOMobjects", referring to The System Object 
Model (SOM) and the Component Object Model (COM), 
Jul. 7, 1994, pp. 1-5 [originally retrieved on Feb. 6, 2000, 
this copy retrieved on Sep. 14, 2001]. Retrieved from the 
Internet <URL: http://www-4.ibm.cora/software/ad/som/li- 
brary/somvscom.html>. 

(List continued on next page.) 

Primary Examiner — Majid Banankhah 

(74) Attorney, Agent, or Firm — David W. Victor; Konrad 

Raynes Victor & Mann LLP 



(57) 



ABSTRACT 



Disclosed is a system, method, and program for implement- 
ing components of a user interface as an object. A user 
interface is implemented in a first user interface program 
object including elements compatible with a first user inter- 
face program. A standard application program interface 
(API) calling a first standard object to create a second 
standard object as an element of the first standard object is 
received. The standard API is a member of a set of standard 
APIs, such as the W3C APIs. A second user interface 
program API is generated to create a second user interface 
program object corresponding lo the second standard object. 
The second user interface program object is embedded as an 
clement in the first user interface program object. 

36 Claims, 10 Drawing Sheets 




01/26/2004, EAST Version: 1.4,1 



us 6,675^30 Bl 

Page 2 



OTHER PUBLICATIONS 

"Querylnterface*', pp. 1-5, [retrieved on May 1, 2001]. 
Retrieved from the Internet. 

"Interface Attributes", pp. 1-2, [retrieved on May 1, 2001]. 
Retrieved from the Internet. 

C. Verbowski, "Using COM Objects from Java", Microsoft, 
Corporation, Feb. 1999, pp. 1-34. 

Microsoft Corp., "The Component Object Model: A Tech- 
nical Overview", copyright 2000, pp. 1-20, [retrieved on 



Feb. 6, 2001]. Retrieved from the Internet <URL: http:// 
msdn.microsoft.com/library/techart/msda_comppr.htm. 

I. Kushnirskiy, "Java-to-XPCOM Bridge", Sep. 18, 2001, 
pp. 1-2, [retrieved on Feb. 7, 2000]. Retrieved from the 
Internet <URL: http://www.mozilla.org/projects/bIack- 
wood/conn6ct/>. 

* cited by examiner 



01/26/2004, EAST Version: 1.4.1 



U.S. Patent Jan. 6, 2004 sheet 1 of 10 US 6,675,230 Bl 



FIG. 1 



Mixed 
Statement 
Program 




Mixed 
Statement 
Program 



Bridge 












\ 


\ 




API 




Object 




Object 






Mappings 




Mapping 




Table 













User Interface 



Ul APIs 



Ul Objects 



Layout Engine 



-14 



Native 0/S 
Ojbects and Interfaces 



Java Virtual Machine 



Operating System 



01/26/2004, EAST Version: 1.4.1 



U.S. Patent jan.6,2004 sheet 2 of 10 



us 6,675,230 Bl 



FIG. 2 




Java Ui 
Object 



Node Info 



UI Object 



01/26/2004, EAST Version: 1.4.1 



U.S. Pateet 



Jan. 6, 2004 



Sheet 3 of 10 



US 6,675,230 Bl 




Receive language 
statement from Weblet 



FIG. 3a 




-No- 



10^ 



Pass statement to java 
virtual machine to 
process. 



114 



Process API mappings to 
determine corresponding 
Ul API function. 



110 



Return pointer to 
previously created 
Ul object to include 
with Ul API. 




Yes- 



Use pointer to Ul API 
function to determine 
pointer to Ul object to 
which API function points, 



Use pointer to native API 

function to detemnine 
pointer to COM object to 
which API function points. 




Use method in native object class to 
determine pointer to node info and 
pointer to Ul object in node info.. 



/Go to block 1187\ 
\. in FIG. 3b. J 



136 



Yes 



Generate statement of native Ul 
API call including pointer to Ul 
object listed in table. 



01/26/2004, EAST Version: 1.4.1 



•'I 

U.S. Patent Jan. 6, 2004 Sheet 4 of 10 US 6,675,230 Bl 



FIG. 3b 



116 




116 



Generate statement in Ul 
API to instantiate new Ul 
object. 



118 



(5> 



Generate node info 
object including pointer 
to Ul object. 



120 



Create instance of Ul 
object including pointer to 
node info. 



122 



Create Java object that inherits from 
Ul object class. 



Add pointer to Ul 
object to object table. 




01/26/2004, EAST Version: 1.4,1 



U.S. Patent Jan. 6, 2004 sheet 5 of 10 US 6,675,230 Bl 



200 



FIG. 4 



Bridge 



Kit 



2y4a 



API 
Mappings 



Object 
Table 



2p8a 



Stub Factory 
Class 



206a 



Object 
Mappings 



:02b 



Kit 



204b 



210b 



API 
Mappings 



Object 
Table 



298b 



Stub Factory 
Class 



2p6b 



Object 
Mappings 



220 



226 



User Interface 



222a 





Ul APIs 












Layout Engine 



222b 





Ul APIs 






If 




Layout Engine 



224a 



224b 



Ul Document Object 


1 Document \ 228a 




|Body| 






— ]HTML 


228b 




— ] Ul Element | 









Native O/S Objects and Interfaces 



01/26/2004, EAST Version: 1,4.1 



U.Sc Patent 



Jan, 6, 2004 



Sheet 6 of 10 



US 6,675,230 Bl 



Browser program opens HTML 
page including embedded mixed 
statement program. 




302 



FIG, 5 



Browser creates DOM document for HTML page 
including embedded mixed statement program. 



Load bridge runtime environment kernel. 



Bridge uses Ui API to get pointer 
to the UI document object. 



)14 



308 



Pass pointer to UI object 
to stub factory for kit i. 



Consider next kit i, 
where i = i + 1 . 



Yes 




316 



Return Java document 
object to executing program 



Return error message 
thai object not 
supported. 



01/26/2004, EAST Version: 1.4.1 



U.S. Patent Jan, 6, 2004 sheet 7 of 10 US 6,675,230 Bl 



FIG. 6 



stub factory receives 
pointer to Ul document 
object when HTML 
page opened. 




Stub factory performs 
querylnterface on Ul object. 




354 




-No- 




Return message to bridge 

that Ul object not 
supported by stub factory. 



Yes 

A. 



Create node info pointer 
from Java document 
object to Ul document 
object. 





60 



Return Java 
document 
object 



01/26/2004, EAST Version: 1.4.1 



U.So Patent Jan. 6, 2004 Sheet 8 of 10 US 6,675,230 Bl 



FIG. 7 



Bridge receives W3C API 
calling Java object, including 
any other parameters. 




Use method in native object class to 
determine from node info pointer to Ul 
object associated with called Java object. 



w 

From node info pointer, determine 
stub factory kit i that created object. 



406 




Pass pointer to Ul object and W3C 
API call to stub factory kit i. 




408 




executing program 



01/26/2004, EAST Version: 1.4.1 



U.S. Patent Jan, 6, 2004 sheet 9 of 10 US 6,675,230 Bl 



450 



Stub factory receives pointer to Ul object 
and W3C API call on Java object, and 
any additional parameters. 



FIG. 8 



452 



Stub factory perfonns 
query Interface on Ul object 



Does 

[jiuery return identlfiabte^ 
^fomnation?^ 



4^ 



Return message to bridge 

that Ul object not 
supported by stub factory. 



Yes 



458 




460 



462 



Determine Ul API 
to create element 
from API mappings. 



48^^ 



Determine Ul API 
forW3C APt from 
API mappings. 



468 



Determine stub 

factory i that 
understands the 
embedded element 
to create. 



Execute Ul create 
element API to 
create element 

having tagName. 



Return new Java 
element to bridge. 



Execute Ul 
API on Ul 
Object. 



Return 
message to 
bridge that 
W3C API 
executed. 



y7o 



Pass createElement 
string to determined 
stub factory 1. 



Stub factory i returns 
Java object for new 
element to calling stub 
factory. 



1,478 



480 



Receive 
returned Ul 
element. 



476 



Catling stub factory 
creates node in tree for 
embedded element. 



Create Java element for returned Ul 
element; create node info pointer from 
Java element to returned Ul element. 



482 



01/26/2004, EAST Version: 1.4.1 



U.S. Patent Jan. 6, 2004 sheet 10 of 10 US 6,675,230 Bl 



FIG. 9 



50C 



502 



Bridge receives 
pointer to Ul 
embedded element. 



Pass pointer to Ul 
embedded element and 
W3C API call to stub 
factory for kit i. 



508 



Consider next kit i, 
where 1 = 1 + 1. 



Yes 




Return Java object to 
executing program. 



01/26/2004, EAST Version: 1.4.1 



us 6,- 

1 

METHOD, SYSTEM, AND PROGRAM FOR 
EMBEDDING A USER INTERFACE OBJECT 
IN ANOTHER USER INTERFACE OBJECT 



BACKGROUND OF THE INVENTION 

1. Field of the Invention 

Preferred embodinients provide a nriethod, system, and 
program for implementing a user interface in an object, such 
as a Document Model Object (DOM) object. 

2. Description of the Related Art 

One of the purposes of the Java** programming language 
is to allow programmers to develop applications that can 
execute across operating system platforms. The Java lan- 
guage accomplishes the cross-platform implementation by 
providing an added layer of execution between the under- 
lying operating system and programs written in the Java 
computer language. The Java Platform converts Java source 
code (Java files) to bytecodes (.class files), which are 
machine independent representations of a Java class. Thus, 
the same bytecodes would be created for all operating 
system platforms. The bytecodes are then inputted to a Java 
Virtual Machine program that converts the byte codes to the 
object code in the native machine language of the operating 
system on which the Java Virtual Machine is installed. There 
is a platform-specific Java Mrtual Machine program for each 
platform on which Java programs can execute. 

Java and JDBC arc trademarks of Sun Microsystems, Inc.; Microsoft is a 
registered trademark of Microsoft Corporation; OS/2 is a registered trademark 
of International Business Machines Corporation; Netscape is a registered 
trademark and Netscape Communicator, Netscape Navigator, Mozilla are 
trademarks of Netscape Communications Corporation. 

All Java programs utilize Java specific toolkits to imple- 
ment a graphical user interface for Java, which is based on 
the Java look-and-feel. The purported goal of the Java 
look-and-feel is to provide a distinctive platform-indepen- 
dent appearance and standard behavior. To implement the 
Java look-and-feel, Sun Microsystems, Inc. provides the 
Abstract Window Toolkit (AWT) and Swing components 
which are classes that implement a Java graphical user 
interface (GUI). One drawback to implementing the GUI in 
the Java look-and-feel is that the Java look-and-feel is 
significantly different from the look-and-feel implemented 
in the native operating system, such as Windows, OS/2, 
etc,** Thus, users running a Java program on a particular 
operating system platform will have to use the Java GUI 
interface which differs from the operating system GUI 
interface to which they are accustomed. These differences 
can discourage users from adopting Java applications, espe- 
cially when other application programs, such as those imple- 
mented in C++, all use the same native API function calls to 
implement the native operating system GUI components. 
Sun Microsystems, Inc. addresses this problem by continu- 
ally trying to incorporate elements of common operating 
system platforms into the Java look-and-feel. However, this 
approach consistently leaves the Java look-and-feel a step 
behind what is currently implemented in the operating 
system platform. 

Java and JDBC arc trademarks of Sun Microsystems, Inc.; Microsoft is a 
registered trademark of Microsoft Corporation; OS/2 is a registered trademark 
of International Business Machines Corporation; Netscape is a registered 
trademark and Netscape Communicator, Netscape Navigator, Mozilla are 
trademarks of Netscape Commimications Corporation. 

Another drawback with the Java GUI interface is that the 
Java interface must be converted to Java bytecodes and then 
to native operating system commands using the Java Virtual 
Machine layer. This extra layer of compilation for the user 
interface slows down the execution of Java programs on the 
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native operating system. Non-java programs that use the 
native operating system API function calls to implement the 
GUI do not have this problem as they directly call the native 
operating system API functions that implement the GUI and 
5 do not need an additional layer of conversion as in the case 
of Java. 

Another drawback with Java is that Java application 
programs, including Java Applets that often execute within 
a Java enabled HTML web browser, are confined to execut- 

10 ing within the Java area of execution. An executing Java 
program cannot interact with other components and objects 
in the operating system. For instance, a Java applet execut- 
ing within a web browser cannot access tables and data 
outside of the area of execution of the applet, even if such 

15 tables are in the HTML document displayed in the web 
browser 

To address this problem, Microsoft has provided a mecha- 
nism to allow Java applications to access the Microsoft 
operating system component objects, referred to as COM 

20 objects. COM objects are used to store reusable software 
components. A component is a reusable piece of software in 
binary form that can easily interface with components from 
different vendors. For example, a spell checking component 
can be used with word processing programs from different 

25 programs. 

Component objects are accessed through interfaces. An 
interface is a strongly -typed group of semantically-related 
functions, also called "interface member functions." The 
interface is defined according to its use and behavior. A 

30 client system or process calls the interface to access the 
implementation of an object and requests the object's ser- 
vices. The interface includes member functions that act upon 
the object. The client maintains a pointer to the interface 
which is, in actuality, a pointer to an array of pointers to the 

35 object's implementations of the interface member functions. 
When calling member functions, the caller would con- 
struct a COM API (application program interface) with an 
argument which is the pointer to the object instance itself. 
The interface would then access the code in the object to 

40 carry out a particular operation or set of operations. Further 
details of the Microsoft Corporation implementation of 
COM is described in the publication "The Component 
Object Model Specification, Draft Version 0.9" (Copyright 
1992-95 Microsoft Corporation), which publication is 

AS incorporated herein by reference in its entirety. 

Microsoft Corporation currently provides an architecture 
to make Windows COM objects available to Java programs. 
The Microsoft Java Virtual Machine (VM) internally uses a 
Java-Callable Wrapper (JCW) to represent a COM object in 

50 Java. JCWs appear to Java developers as generic Java 
objects. JCWs are programmatically manipulated in exactly 
the same way as any regular Java object. The JCW contains 
all the information necessary for the Microsoft VM to 
manipulate the underlying COM object. COM objects can 

55 be used in the same manner as Java objects because the 
Microsoft VM exposes COM objects as Java objects. 
Microsoft further provides J/Direct to access Windows API 
COM functions to create new instances of COM classes. 
J/Direct provides classes that map COM functions to Java 

60 calls. Further details of how Microsoft provides Java appli- 
cations access to COM objects are described in the publi- 
cations "Using COM Objects from Java," by Chad Ver- 
bowski (Copyright Microsoft January 1999) and 
"Integrating Java and Com", by Chad Verbowski (Copyright 

65 Microsoft, January 1999), which publications are incorpo- 
rated herein by reference in their entirety. 

By using J/Direct to expose COM objects to Java appli- 
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cations, J/Direci allows the Java application to access 
objects outside of the area of execution of the Java appli- 
cation. However, Microsoft's J/Direct system is limited to 
the Microsoft operating systems and Microsoft Java Virtual 
Machine. Microsoft's proprietary approach defeats the Java 
goal of allowing the application program to execute across 
different operating system platforms. A Java developer who 
writes a Java application using the J/Direct interfaces to 
COM objects is limited to the Microsoft Windows platform 
and cannot access the COM version of objects in other 
operating systems, thus defeating the cross-platform goal of 
Java. 

Thus, there is a need in the art for an improved platform 
independent technology to allow Java applications to access 
operating system components and objects outside of the area 
of execution of the Java program to take advantage of the 
objects and interfaces available in different operating system 
platforms. 

There is also a need in the art to allow Java applications 
to use more commonly used graphical user interface (GUI) 
components, other than the GUI components offered in Java 
tool kits, such as AWT. 

SUMMARY OF THE PREFERRED 
EMBODIMENTS 

To overcome the limitations in the prior art described 
above, preferred embodiments disclose a method, system, 
and program for implementing components of a user inter- 
face as an object. A user interface is implemented in a first 
user interface program object including elements compatible 
with a first user interface program. A standard application 
program interface (API) calling a first standard object to 
create a second standard object as an element of the first 
standard object is received. The standard API is a member of 
a set of standard APIs, such as the W3C APIs. A second user 
interface program API is generated to create a second user 
interface program object corresponding to the second stan- 
dard object. The second user interface program object is 
embedded as an element in the first user interface program 
object. 

In further embodiments, the second standard object is 
associated with the second user interface program object. 
The second standard object is returned to a program includ- 
ing standard API calls to the second standard object. 

In still further embodiments, the first user interface pro- 
gram may comprise a browser program and the second user 
interface program comprises a plug-in prograni to the 
browser program. Further, the set of standard APIs may 
comprise the W3C DOM APIs and the first and second user 
interface programs implement the W3C DOM. 

Preferred embodiments make available standard API 
interfaces, such as those specified in the W3C DOM 
specifications, for use with programs written in cross- 
platform languages, such as Java, to allow the application 
program to manipulate objects and interfaces in a user 
interface program, such as a Mozilla browser or Internet 
Explorer, that implements the standard API interfaces. This 
extends the Java environment by making any object acces- 
sible to the user interface program accessible to the Java 
application program. The preferred embodiments take 
advantage of the fact that many user interface programs, 
such as the common web browsers, implement the W3C 
DOM specification and API interfaces. Preferred embodi- 
ments allow objects in the application program to map to a 
corresponding implementation of that object in the user 
interface program. By providing a mapping of the W3C 
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interfaces to the specific user interface implementation and 
the application program objects to the user interface objects, 
the prefenred embodiments allow Java developers to utilize 
W3C standard interfaces to access objects in the user 
5 interface program to allow the Java program to use the user 
interface. 

By making user interface objects accessible to the Java 
program, the Java program can implement its user interface 
using the interface component objects of the user interface 

10 program. This allows a Java program user interface to have 
the same "look-and-feel" as the user interface program, e.g., 
Internet web browser, as the Java program is ultimately 
using the same user interface component objects utilized by 
the user interface program. Because the translator programs 

15 of the preferred embodiments allow the Java application 
program and standard API interfaces to execute across 
different operating system platforms, preferred embodi- 
ments provide a mechanism for a Java program to access and 
manipulate user interface and operating system objects 

^0 across operating system platforms 

BRIEF DESCRIPTION OF THE DRAWINGS 

Referring now to the drawings in which like reference 
25 numbers represent corresponding parts throughout: 

FIG. 1 illustrates elements of the computer architecture in 
which preferred embodiments arc implemented; 

FIG. 2 illustrates data structures used to link a Java object 
to a user interface object in accordance with preferred 
30 embodiments of the present invention; 

FIGS. 3a, b illustrate logic to transform Java program 
language statements to code that can be directly executed by 
the native operating system in accordance with preferred 
embodiments of the present invention; 

FIG. 4 illustrates an alternative architecture where the 
bridge includes kits to map W3C APIs to multiple user 
interface program APIs in accordance with preferred 
embodiments of the present invention; 

FIG. 5 illustrates logic to create the user interface docu- 
ment object manipulated by the user interface program to 
implement the browser window for the HTML page in 
which the mixed statement program executes in accordance 
with preferred embodiments of the present invention; 
45 FIG. 6 illustrates logic implemented in a stub factory to 
create an association of a Java document object and the user 
interface document object in accordance with preferred 
embodiments of the present invention; 

FIG. 7 illustrates logic implemented in the bridge to 
50 process a W3C API call to a Java object in accordance with 
preferred embodiments of the present invention; 

FIG. 8 illustrates logic implemented in a stub factory to 
transform the W3C API to a user interface API in accordance 
with preferred embodiments of the present invention; and 

FIG. 9 illustrates logic implemented in the bridge to 
handle a created user interface embedded element in accor- 
dance with preferred embodiments of the present invention. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

In the following description, reference is made to the 
accompanying drawings which form a part hereof, and 
which illustrate several embodiments of the present inven- 
65 tion. It is understood that other embodiments may be utilized 
and structural and operational changes may be made without 
departing from the scope of the present invention. 
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FIG. 1 illustrates the componeats of the computer archi- 
tecture in which preferred embodiments are implemented. 
Mixed statement programs Zqj b, c, comprise programs 
written in the Java programming language, or any other 
cross-platform language, that may include the standard API s 
interfaces developed by the World Wide Web Consortium 
(W3C) for the Document Object Model (DOM) application 
programming interface (API). Thus, these programs 2a, k c 
include language statements from difiE'erent programming 
languages or protocols, such as Java and non-Java standard 
API interfaces, such as the W3C API interfaces. 

The DOM model is a standard interface used to define the 
structure of documents, particularly HTML and XML docu- 
ments. In the DOM specification, the term "document" is 
used in the broad sense to include the components of a 
textual document as well as components of an application 
program. The DOM interface represents the document or 
application program as a hierarchical arrangement of nodes. 
All the components of an HTML or XML document, includ- 
ing data as well as program elements, such as the user 
interface elements, can be expressed as hierarchically 
arranged nodes. The W3C DOM specifications provide API 
interfaces to access, change, delete or add nodes to the DOM 
representation of a document, or appUcation program. The 
API interfaces specified in the DOM specifications are ^5 
referred to herein as "W3C API interfaces." 

In preferred embodiments, the mixed statement programs 
2a, b, c may incorporate the W3C API interfaces of DOM 
specifications, such as the DOM level 1 Core, including 
DOM Level 1 HTML, which provides W3C interfaces 30 
representing all of the HTML 4.0 elements, DOM Level 2 
Core which comprises modifications to DOM Level 1, DOM 
Level 2 Cascading Style Sheets, etc. Many browsers such as 
Microsoft Internet Explorer version 5 and Mozilla based 
browsers, such as Netscape Communicator, implement the 35 
W3C DOM Level 1 HTML interface, as well as Cascading 
Style Sheets. In this way, developers creating mixed state- 
ment programs 2a, b, c may utilize the W3C API interfaces 
as specified in the W3C specifications, such as the "Docu- 
ment Object Model (DOM) Level 1 Specification, Version 40 
1.0" (Oct. 1, 1999) and ''Document Object Model (DOM) 
Level 2 Specification, Version LO" (Dec. 10, 1999), which 
are incorporated herein by reference in their entirety, and 
which include the DOM Level 1 HTML, DOM Uvel 2 
Core, DOM Level 2 CSS, DOM Level 2 Views and Events, 45 
DOM Level 2 HTML, DOM Level 2 Stylesheets, DOM 
Level 2 CSS, DOM Level 2 Traversal, etc. 

After the mixed statement programs 2a, b, c are written to 
include Java programming language statements as well as 
W3C API interface calls, the mixed statement program 2a, 50 
b, c is processed by a bridge 4. The bridge 4 maintains an 
API mapping 8 of W3C API interfaces to the corresponding 
implementation of the W3C API interface in a user interface 
(UI) program 10 that implements the DOM, such as Internet 
Explorer, Netscape Communicator and Navigator, Mozilla, S5 
the Scalable Vector Graphics format used by Adobe 
Systems, Inc., or any other user interface that implements 
the DOM. 

The user interface program 10 includes user interface (UI) 
APIs 12 that are used to manipulate user interface (UI) 60 
objects 14 that implement the elements and components of 
the observable user interface features produced by the user 
interface program 10. A user interface layout engine 16 
would transform the UI APIs 12 and UI objects 14 to the 
native operating system objects and interfaces 18 on which 65 
the browser layout engine 16 was written to operate. For 
instance, Internet browsers, such as Internet Explorer and 



,230 Bl 

6 

Netscape Navigator, include different layout engines for 
different operating systems to transform the user interface 
APIs 12 and objects 14 to native operating systems objects 
and interfaces 18. The browser layout engine has all the 
mappings to access and control the native operating system. 
The Mozilla browser layout engine, referred to as the Next 
Generation Layout (NGLayout) or Gecko layout engine, 
processes the API functions that implement the W3C DOM 
Level 0, Level 1, and Level 1 HTML, as well as cascading 
style sheets and other DOM standards, and generates the 
native operating system calls to execute the requested opera- 
tion. 

The bridge 4 API mapping 8 would include for each 
supported W3C API interface, the corresponding UI API 12 
interface in the user interface program 10. In preferred 
embodiments, the API mapping 8 would map the Java class 
names to the unique identifiers of the user interface APIs 12. 
The user interface APIs 12 would in turn manipulate 
browser objects, such as browser COM objects. 

The bridge 4 further includes an object mapping 20 of 
Java objects, that may be called from within the mixed 
statement programs 2a, b, c. The mixed statement programs 
2a, b, c would include a W3C API interface call to a Java 
object, which maps to a corresponding UI COM object 14 in 
the user interface 10. The mixed statement programs 2a, b, 
c may include W3C API calls instantiating and manipulating 
Java objects, that map to UI objects 14 in the user interface 
10, For instance, the object mapping 10 for Internet Explorer 
describes the mapping of Java objects to COM objects, 
whereas for Mozilla based browsers the mapping 10 is to 
XPCOM objects in the Mozilla browser. The bridge 4 uses 
the API 8 and object 20 mappings to transform W3C API 
interfaces in the mixed statement programs 2a, c to the 
corresponding user interface APIs 12 and objects 14 that can 
be executed directly by the user interface layout engine 16, 
which would then access the underlying operating system 
interfaces and objects 18 to execute the action. The bridge 4 
will forward Java language statements to a Java Virtual 
Machine (JVM) 22 to process. Thus, in preferred 
embodiments, the bridge 4 separately processes the Java 
language statements to generate bytecodes executable by the 
native operating system and separately processes the W3C 
API interfaces to produce language statements and object 
code that the user interface 10 can directly execute. 

The W3C API interfaces include numerous methods to 
implement objects in the user interface 10. By exposing a 
Java program, or mixed statement programs 2a, b, c, to the 
W3C API interfaces, a mixed statement program 2a, b, c 
including Java program statements can access any user 
interface feature and object that the user interface program 
10 is capable of implementing. Thus, with the preferred 
computer architecture, the Java program is no longer con- 
strained to the Java programming space, and may extend the 
Java program to other objects and programs available in 
commonly used user interface programs. For instance, the 
mixed statement programs 2a, b, c may include the W3C 
HTML API interfaces to implement a user interface using 
the underlying UI objects 14 supported in the user interface 
10. With this approach, the mixed statement programs 2a, b, 
c can generate a user interface that has the same look-and- 
feel as the commonly used user interface 10 with which the 
user is intimately familiar. 

Because the bridge 4 maps to user interface APIs 12, the 
mixed statement programs 2a, b, c may execute on any 
operating system on which the user interface 10 may 
execute. The user interface layout engine 16 will handle the 
conversion of the browser APIs 12 and objects 14 to the 
specific operating system 6 platform. 
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As discussed the object mapping 20 exposes user inter- 
face objects 14 to the mixed statement programs 2a, b, c to 
provide Java applications access to the user interface 10 
functions and elements. The object mapping 20 provides a 
linkage of an instance of a user interface object 14, e.g., 
COM object, XPCOM object, etc., to a conresponding Java 
object that may be manipulated by the mixed statement 
program la, b, c. When a W3C API interface is used in a 
mixed statement program la, b, c to instantiate an instance 
of a java object that corresponds to a native operating system 
object, the Bridge 4 would generate the Java native object 32 
and node info object 34 data structures illustrated in FIG. 2 
to provide a linkage between the Java object 30 and the 
corresponding user interface (UI) object 36. The node info 
object 34 comprises a pointer to the instantiated UI object 
36. The Java native object 32 has a pointer to the node info 
object 34. The Java object 30 inherits all the properties of the 
Java native object class and can access all the functions 
implemented in the Java native object class. In this way, the 
Java object 30 is bound to the corresponding UI object 36 
through the Java native object 32 and the methods that allow 
the Java object 30 to access the node info object 34, which 
can then be used to access the UI object 36. 

In preferred embodiments, the bridge 4 maintains an 
object table 24 (FIG. 1), which includes the value of the 
pointer for any native operating system object, e.g., COM 
object, linked to a Java object. The bridge 4 uses the object 
table 24 to avoid creating multiple instances of the same 
Java object. If a pointer to a user interface object is listed in 
the table 24, then the bridge 4 will have the API function 
calling such object use the already existing instance of the 
object instead of instantiating an additional instance of the 
same object. 

FIGS. 3fl, b illustrate logic implemented in the bridge 4 to 
process language statements in the mixed statement pro- 
grams la, b, c. Control begins at block 100 with the bridge 
4 receiving a language statement in one mixed statement 
program la, b, c. The bridge 4 determines (at block 102) 
whether the statement is a W3C API function call for which 
there is an API mapping 8. If not, then the bridge 4 passes 
(at block 104) the statement to the Java virtual machine 22 
to transform to native machine code, i.e., bytecodcs. 
Otherwise, the bridge 4 processes (at block 106) the API 
mappings 8 to determine the corresponding user interface 
API 12 function call, which may comprise the GUID of the 
API function call. If the UI API 12 function is to instantiate 
a new UI object 14 (at block 108), then the bridge 4 uses (at 
block 110) the pointer to the API function call to determine 
the pointer to the UI 14 object in a manner known in the art. 
The bridge 4 then determines (at block 112) whether the 
pointer to the UI object 14 is listed in the object table 18. If 
so, the bridge 4 returns (at block 114) the pointer to the UI 
object 14 listed in the object table 18 to the user interface 
API 12 function, and then would proceed back to block 100 
to process further statements in the mixed statement pro- 
gram la, b, c. This ensures that the bridge 4 would never 
create UI objects 14 for the same intended object in order to 
maintain the uniqueness of each UI object 14. Otherwise, if 
there is not a pointer to the UI object 14 listed in the object 
table 18, then control proceeds to block 116 in FIG. 3^ to 
generate UI APIs 12 and the accompanying linkage data 
structures from the corresponding Java object 30 to a new UI 
object 36. 

At block 116 in FIG. 3f>, the bridge 4 generates the UI API 
function 12 to create a new instance of the UI object 14. The 
bridge 4 then creates (at block 118) a node info object 34 that 
includes a pointer to the instantiated UI object 36. A Java 
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user interface (UI) object 32 is created (at block 120) to 
implement the Java UI object class and includes a pointer to 
the node info object 34. The Java object specified in the 
W3C API function instantiating the Java object is then 
created and defined (at block 122) to inherit from the Java 
UI object class. In this way, an instance of the Java object 
and instances of the Java UI object 32 and node info object 
34 are created to provide linkage from the Java object 30 to 
the corresponding UI object 36. The pointer to the new UI 
object 36 is then added (at block 124) to the object table 24 
to ensure that additional instances of the same UI object are 
not created. From block 124, control would transfer back to 
block 100 to process any further statements in the mixed 
statement program la, b, c. 

If, at block 108 in FIG. 3a, the bridge 4 determines that 
the W3C API function call is not to instantiate a new Java 
object, then the bridge 4 further determines (at block 130) 
whether there is a Java UI object 32 for the Java object 30 
that includes a pointer to a node info object 34, If a Java UI 
object 32 has not yet been created for the Java object 30, 
then the bridge 4 uses the pointer to the UI API function 12 
determined from the API mappings 8 to determine (at block 
132) the pointer to the UI object 14 to which the UI function 
interfaces. From block 132, control proceeds to block 118 in 
FIG. 36 to create the linkage data structures from the Java 
object 30 specified in the W3C API function call to the 
existing UI object 36. 

If, at block 130, there is already a Java UI object 36 for 
the Java object 30 in the W3C API function call, then the 
bridge 4 uses (at block 134) a method in the Java UI object 
class to determine the pointer to the node info object 34 from 
the Java UI object 32 for the Java object 30 called in the 
W3C API function. The functions in the Java UI object class 
are also used to query the node info object 34 to determine 
the pointer to the UI object corresponding to the Java object. 
After obtaining the pointer to the UI object, the bridge 4 then 
constructs (at block 136) a statement comprising the deter- 
mined user interface function call including the pointer to 
the UI object determined from the node info object 34, 
resulting in a user interface function call to a UI object. 

In further embodiments, it is possible that multiple UI 
objects and interfaces are used to implement a single W3C 
class. In such case, the bridge 4 would create an additional 
data structure referred to as a proxy object to which the node 
info object points. This proxy object would in turn include 
pointers to multiple UI interfaces providing access to one or 
more UI objects that implement the W3C interface. In this 
way, the proxy object exposes the Java object and corre- 
sponding W3C API interface to one or more UI interfaces 
and objects. When processing calls to such a Java object, the 
bridge 4 would transform the call to the Java object to the 
multiple UI API interfaces specified in the proxy object to 
which the node info for the Java object points. 

The result of the logic of FIGS. 3^?, b is that the bridge 
transforms W3C API function calls added to mixed state- 
ment programs la, b, c to the implementation of those W3C 
calls in the user interface 10. Preferred embodiments exploit 
the fact that many current user interfaces, such as Mozilla 
browsers, Microsoft Internet Explorer version 5, Adobe 
Scalable Vector Graphics, etc., implement the W3C DOM 
interfaces. A program developer may then include W3C API 
calls in a mixed statement program also including Java 
language statements to directly access the user interface 
objects maintained in the operating system. Preferred 
embodiments thus allow Java developers to extend Java 
programs beyond the Java runtime environment and utilize 
existing structures and objects implemented in the operating 



01/26/2004, EAST Version: 1.4,1 



us 6,6' 

9 

system. This preferred embodiment computing architecture 
allows a Java program, such as an Applet, to be a full dtizen 
of the operating system as the mixed statement program 2a, 
b, c can access any user interface program 10 interface and 
object defined in the operating system that implements a 
W3C API interface. 

In preferred embodiments, the mixed statement programs 
may execute using multithreading techniques known in the 
art to concurrently execute multiple mixed statement pro- 
grams in a single browser or web page. 

Further, with the preferred embodiment architecture, the 
Java developer may expose data in any object accessible to 
the user interface, including DOM trees, to java tools. For 
instance, the mixed statement program may include Java 
Database Connectivity (JDBC**) calls to perfonm queries to 
access data from a database. The program could then include 
W3C API interface calls to insert database records returned 
from the JDBC calls into the DOM for a displayed HTML 
page to display the returned data in the HTML page. 
Alternatively, the mixed statement program may call a Java 
Bean application to perform various calculations or opera- 
tions on data, and then include W3C API interfaces to insert 
the results of the operation from the Java program in the 
HTML DOM to display in the web page. 

*• Java and JDBC arc trademarks of Sun Microsystems, Inc.; Microsoft is a 
registered trademark of Microsoft Corporation; OS/2 is a registered trademark 
of International Business Machines Corporation; Netscape is a registered 
trademark and Netscape Communicator, Netscape Navigator, MoziUa are 
trademarks of Netscape Communications Corporation. 

The bridge 4 may be included in a Java Development Kit 
(JDK) or Java Runtime Environment (JRE) package for a 
specific operating system, e.g., Limix, Windows, OS/2, or 
any other supported operating system platform. The API 
mappings 8 would map each supported W3C API interface 
to the corresponding implementation of that interface in a 
user interface capable of executing on the specific operating 
system. In this way, the mixed statement program can 
execute on any operating system for which there is a version 
of the JDK or JRE including the bridge 4 and API mappings 
8. 

Using the W3C Interface to Manipulate the DOM 
The above implementation concerned the general map- 
ping of W3C API interfaces to user interface APIs 12 to 
manipulate the user interface objects 14 from a Java mixed 
statement program. Another aspect of the DOM is that it 
allows a document, or program or any component in the 
system to be expressed as a hierarchical relationship of 
objects that may separately be manipulated. Each element is 
maintained with attributes of the element. This allows a user 
to delete, add, or change an element, change its content or 
add, delete or change an attribute. For instance, the different 
parts of a document, such as sections, images, chapters, etc., 
may each be expressed as a DOM element in a hierarchical 
tree of DOM elements that define the entire document. 
Further, an HTML page may be expressed in a DOM tree 
where the elements of the HTML page, including user 
interface elements and program components, are expressed 
in a hierarchical relationship. The DOM makes all of the 
objects in a page, e.g., and HTML or XML page, such as 
images, forms, and even CSS properties, accessible to an 
application program. Various W3C API functions are avail- 
able for manipulating DOM objects arranged in a hierarchi- 
cal relationship. By manipulating particular DOM objects of 
an HTML page using W3C API interfaces or their corre- 
sponding implementation in a particular web browser or 
operating system, the user may specifically alter partictilar 
sections of the HTML page by manipulating the element(s) 
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without affecting other sections of the HTML page defined 
in other elements. 

Currently, the DOM is widely accepted as a standard for 
defining components within documents and applications, 

5 especially those related to the Internet, such as XML and 
HTML documents. In fact Microsoft Explorer 5.0 and 
Mozilla implement HTML using the DOM model and APIs. 
Further details of expressing document and application 
components in a DOM tree are described in the DOM 
specifications incorporated by reference above. 

With the preferred embodiment bridge 4, a developer may 
use W3C API interfaces to implement the elements of a 
program or document, e.g., web browser, HTML page, user 
interface, etc., in a DOM tree and control the user interface 
through W3C API interfaces that manipulate the nodes of the 
DOM that implement the user interface. The W3C includes 
specific API interfaces to access, manipulate, create, modify 
and destroy node elements in a DOM tree. In such case, the 
API mappings 8 would include mappings for W3C API 
interfaces to access and manipulate nodes in a DOM tree to 

20 the corresponding command in the underlying browser or 
native operating system. In this way, the program developer 
may insert W3C API interfaces in a mixed statement pro- 
gram to manipulate a DOM implemented by the user inter- 
face program 10, which the bridge 4 would transform to API 

25 interfaces in the user interface program 10. 

With the preferred embodiment architecture, the program 
developer can access the browser layout engine to generate 
the user interface for a program written in a different 
program language, such as Java. This allows the program 

30 developer to "draw" the user interface using use the HTML 
browser on the user's system to provide a user interface that 
has the same "look-and-feeF* presented by the installed 
browser. Moreover, by using the APIs of the browser, the 
bridge 4 does not have to be capable of providing the 

35 transformation to native operating system machine code as 
all such transformations are handled by the web browser's 
layout engine. Such implementations of the bridge to inter- 
face with the browser engine frees the Java programmer 
from the Java "look-and-feel" and the limitations of the Java 

40 AWT and Swing kits. With preferred embodiments, the 
look-and-feel of the mixed statement program would have 
the same user interface and look-and-feel of the browser 
already installed on the user's system. 
With the preferred embodiments, a program developer 

45 may write the user interface using the W3C API interfaces 
related to HTML and the program logic in Java. Using the 
W3C interfaces, the mixed statement program could include 
event listeners to modify the HTML page upon the occur- 
rence of certain events such as user input. Another way to 

50 write the mixed statement program is to embed the program 
in an empty HTML page in a manner similar to a Java 
Applet. During runtime, the mixed statement program 
embedded in a Web page Hke an Applet may dynamically 
add buttons, tables, text and graphics to the HTML page by 

55 manipulating the HTML DOM. Still further, the mixed 
statement program may include a combination of precon- 
structcd HTML elements for the user interface as well as 
adding elements by manipulating the DOM. Yet further, the 
program can be written to run as a standalone application, 

60 using the HTML elements to generate a separate GUI 
window, like any other operating system window. In such 
case, the mixed statement program may utilize the browsers 
engine to generate the user interface without necessarily 
having the look and feel of a typical HTML page, including 

65 the browser chrome. 

In preferred implementations, the bridge 4 including its 
API mappings would be implemented in different packages 
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to interface with different operating system platforms. Thus, 
the Bridge may be included in the JRE and JDK kits for each 
operating system platform that supports Java to map the 
W3C API interfaces to the native operating system API 
interfaces. Further, the bridge may be implemented in the 
Java code included with Java enabled browsers to map the 
W3C APIs to the API interfaces used by the browser engine. 
This would allow a user to download a mixed statement 
program through the web browser and execute the mixed 
statement program in the web browser. The executing mixed 
statement program, through the Bridge, would issue W3C 
API calls that are mapped to the corresponding browser 
implementation of those calls. The browser layout engine 
would then directly execute the mapped API calls to gen- 
erate the user interface and manipulate components 

Embedded DOM Trees 

Preferred implementations provide a methodology for 
allowing two different implementations of the DOM func- 
tion as one DOM tree embedded in another DOM tree. For 
instance, the DOM tree may include both the Microsoft 
Internet Explorer nodes and Adobe Scalable Vector Graphics 
(SVG) nodes. In this way, the DOM tree includes objects 
and components that may be implemented by the Microsoft 
Internet Explorer layout engine and a plug-in program, such 
as the Adobe Scalable Vector Graphics (SVG). In this way, 
a mixed statement program can include calls to objects that 
are directed toward different implementations of the DOM. 

FIG, 4 illustrates an alternative implementation of a 
bridge 200 capable of handling APIs for different user 
interface programs implementing the DOM, such as 
Microsoft Internet Explorer, Adobe Scalable Vector Graph- 
ics (SVG) plug-in, a Mozilla browser, etc. Kits 202a, b 
include the components to implement each of the user 
interface (UI) programs in the bridge 200. The kits are 
loaded into memory when the bridge runtime environment is 
loaded into memory. The kits 202a, b include API mappings 
204a, b that map W3C API calls to APIs in the user interface 
program; object mappings 206 a, b that provide a mapping 
from a Java object to a user interface (UI) object, such as the 
mapping shown in FIG. 2, for the user interface program 
implemented in the kit 202a, b; and an object table 210a, b, 
such as the object table described above that provides 
information on existing user interface (UI) objects that are 
associated with a Java object. Each kit 202a, b further 
includes a stub factory class 208a^ b that provides methods 
to handle W3C API calls to objects intended for the user 
interface program (e.g., Internet Explorer, Mozilla, SVG, or 
any other DOM compliant plug-in program) implemented 
by the kit 202a, b. 

The user interface 220 receives the UI APIs 222a, 2226 
for the different user interface programs that the bridge 200 
translates from W3C APIs provided from a mixed statement 
program or generated in response to a user invoked event. 
The user itnerface 220 includes a layout engine 22Aa, b for 
each user interface program that it implements. The layout 
engines 224aj b translate the user interface (UI) APIs 222a, 
222b to native operating system commands that can be 
directly executed by the operating system. For instance, the 
user interface 220 may include the Adobe Scalable Vector 
Graphics (SVG) and Microsoft Internet Explorer layout 
engines to execute W3C API calls using Internet Explorer 
and Adobe SVG. 

The user interface 220 would further maintain a user 
interface (UI) document 226, which in preferred embodi- 
ments is implemented as a DOM document tree including 
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nodes for the base user interface program providing the main 
window in which the user interface is implemented, such as 
a browser program. The document node 228a provides he 
root node for the document object. This user interface (UI) 

5 element 2286 would be placed as a child leaf node to any 
element within the document object where the instances of 
the plug-in or secondary user interface program are imple- 
mented. For instance, if SVG components are implemented 
in a particular HTML section or are of the main Internet 
Explorer tiser interface, then each instance of the SVG 
components would be implemented as a child node to the 
Internet Explorer node for the component in which the SVG 
component is implemented or drawn. Each SVG element in 
the DOM tree 226 would include further child nodes imple- 
menting the SVG components at that particular location. In 
this way, one or more SVG DOM trees are embedded in the 
main user interface, e.g., Internet Explorer or Mozilla, DOM 
tree. The main user interface program renders the back- 
ground and environment in which all other elements or 
plug-ins operate. 

The UI document object implements 226 each of the 
nodes of the document object as user interface (UI) objects, 
such as COM objects. 

FIGS. 6-9 illustrate logic implemented in the bridge 200 

25 and stub factories 208 a, b to allow a mixed statement 
program having W3C APIs to manipulate a DOM object 
having DOM trees from different user interface programs, 
e.g., Internet Explorer and the Adobe SVG. FIG. 5 illustrates 
logic implemented in the bridge 200 when the mixed state - 

30 ment program begins executing. Control begins at block 300 
with a browser program, or other user interface program 
providing the main user interface, opening an HTML page 
including an embedded mixed statement program. The 
browser would use a user interface (UI) or browser API, e.g., 

35 a Microsoft COM of Mozilla XPCOM API, to create (at 
block 302) a UI document object 226, i.e., a Internet 
Explorer HTML COM object, for the HTML page including 
the mixed statement program. This user interface (UI) 
document object 226 comprises the user interface imple- 

40 mentation of the DOM document, which with Internet 
Explorer would comprise a COM object or with Mozilla an 
XCOM object. The browser then loads (at block 304) the 
bridge 200 runtime environment kernel. 

The bridge 200 then uses (at block 306) a user interface 

45 (UI) API, e.g., a Querylnterface, to obtain the pointer to the 
user interface (UI) document object 226, which with Internet 
Explorer would be a COM object. The bridge 200 passes (at 
block 308) the pointer to the user interface (UI) document 
object to the stub factory in kit i, e.g., stub factory 208a in 

50 kit 202a, and waits for a response from the stub factory 
208a. If the response indicates that the stub factory 208a 
does not support or own that object, e.g., the object is an 
Internet Explorer object and the stub factory is for the 
Scalable Vector Graphics (SVG) user interface program, 

55 then the bridge 200 determines (at block 312) if there arc 
further kits not considered. If so, then the bridge 200 
considers (at block 314) the next (i+l)th kit202^7 and returns 
to block 308 to pass that next kit 202Zj the pointer to the user 
interface (UI) document object. 

60 If (at block 312) there are no further kits to consider, then 
the runtime environment has not loaded a kit that is capable 
of handling the user interface (UI) object. In such case, an 
error message indicating that the object is not supported is 
returned (at block 316) to the bridge. If the response from the 

65 stub factory (received at block 310) is a returned Java 
document object, then the bridge 200 returns (at block 318) 
the Java document object, or HTMLdocument, to the 
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executing mixed statement program to use to reference the 
document object, i.e., DOM object implementing the HTML 
page. 

FIG. 6 illustrates logic implemented in the stub factory 
classes 208f7, b to handle the pointer to the user interface 
(UI) document object received from the bridge at block 308 
in FIG. 5 when the browser initially opens the HTML page 
including an embedded mixed statement program. Control 
begins at block 350 with the stub factory 208a, b receiving 
the user interface (UI) document object from the bridge 200. 
The stub factory then performs (at block 352) a queryinter- 
face or other query user interface (UI) API to obtain infor- 
mation on the received UI document object (e.g., COM, 
XCOM object, etc.). 

If (at block 354) the query returns identifiable 
information, then the stub factory 202a, b creates (at block 
358) a node info pointer from the Java document object, e.g., 
Java version of the root to the HTML document, to the UI 
document object. The stub factory 208a, b would further 
update the object mappings 206a, b and object table 210 in 
its kit 202a, b indicating the mapping of the Java document 
object and user interface (UI) document object, or the 
HTMLdocument node comprising the root node to the 
HTML document object. The stub factory 208a; b would 
then return (at block 360) the Java document object to the 
bridge 200. Otherwise, if the query does not return identi- 
fiable information, then the stub factory 208a, b returns a 
message to the bridge 200 that the user interface (UI) object 
is not supported by that particular stub factory. 

Thus, FIGS. 5 and 6 illustrate the process by which the 
initial reference to the root of the user interface (UI) docu- 
ment object and corresponding Java document object are 
obtained and made available by the bridge 200 for later use 
in the mixed statement program when referencing nodes in 
the HTML document object. 

FIG. 7 illustrates logic implemented in the bridge 200 
when receiving, at block 400, a W3C API call to a Java 
object, and perhaps other parameters, form a mixed state- 
ment program. The bridge 200 uses the methods in the native 
object class to determine (at block 402) from the node info 
pointer the user interface (UI) object implementation of the 
called Java object. Each Java object subject to a W3C API 
call would have to have been created earher. The bridge 200 
then determines (at block 404) the stub factory kit i that 
created the Java object, e.g., stub factory 208fl in kit 202a, 
from information maintained in the node info pointer for the 
Java object. In preferred embodiments, the node info pointer 
maintains information on the stub factory kit that created the 
Java object for which the node info pointer provides infor- 
mation. The bridge 200 then passes (at block 406) the 
pointer to the UI object and W3C API call to the determined 
stub factory kit i. 

If a Java object is returned (at block 408), then the bridge 
200 returns (at block 410) the Java object to the mixed 
statement program to use. If a Java object is not returned and 
the stub factory kit i handles the object without returning a 
Java object, then control ends. This state would occur if the 
W3C API manipulates a document element without return- 
ing any data. In such case, the bridge 200 takes no further 
action and processes the next statement in the mixed state- 
ment program. 

FIG. 8 illustrates logic implemented in the stub factories 
208fl, b to handle a user interface (UI) object and W3C API 
calling a Java object corresponding to the user interface (UI) 
object. Control begins at block 450 with the stub factory 
208a, b receiving a pointer to a user interface (UI) object. 
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which may be the user interface program (e.g., Internet 
Explorer, SVG, etc.) implementation of a DOM element, 
and the W3C API call on the Java object corresponding to 
the user interface (UI) object, and any additional parameters. 
For instance, if the W3C API was a createElement method, 
then the interface would specify the name of the document 
object in which the element will exist and the tagName or 
node name of the new element. The stub factory 208a, b 
would then perform (at block 452) the user interface (UI) 
API querylnterface on the user interface (UI) object. For 
instance, if the user interface program implemented by the 
stub factory 208a, b is Internet Explorer, then the API would 
be the querylnterface API. If (at block 454) the query docs 
not return identifiable information, then the stub factory 
208a, b returns (at block 456) a message to the bridge 200 
that the user interface (UI) object is not supported by the 
stub factory 208a, b. 

If (at block 454) the query returns identifiable 
information, then the stub factory 208a, b determines 
whether the W3C API is for a command to create an clement 
having a tagName. If not, then the stub factory 208a, b 
determines (at block 460) from the API mappings 204a, b 
the user interface (UI) API to implement the W3C API. The 
stub factory 208a, then executes (at block 462) the user 
interface (UI) API, which performs some manipulation on 
the user interface (UI) DOM objects and returns (at block 
464) a message to the bridge 200 that processing of the W3C 
API completed. 

Otherwise, if the W3C API is to create a new element, 
then the stub factory 208a, b determines (at block 466) 
whether the tagName of the new element is of the form 
"embed%" element, e.g., embedSVGelement, 
embedRealAudioelement, etc. If so, then the createElement 
method is to embed a DOM tree for another user interface 
program, such as a plug-in, e.g., SVG DOM, into the main 
user interface program DOM tree, e.g., the Internet Explorer 
DOM. If the tagName is to embed a new type of DOM, then 
the stub factory 208a, b detenmincs (at block 468) a stub 
factory i that supports the element being created. The stub 
factory 208a, b would call the different stub factories to find 
one stub factory capable of handling an object of the type 
specified in the tag name. The stub factory 208fl, b would 
then pass (at block 470) the createElement string to the 
determined stub factory i. At block 472, the stub factory i 
would create a Java object, including node information for 
the element being created and return (at block 472) the Java 
object for the new element to the calling stub factory. The 
calhng stub factory 476 would then create a node in the tree 
for the embedded element. 

For instance, if the Internet Explorer receives an Internet 
Explorer createElement command to create an SVG 
element, then the Internet Explorer stub factory would call 
the SVG stub factory to create the new SVG element and the 
Java object for this SVG element, which the Internet 
Explorer stub factory would then include as a node in the 
DOM tree. If the new element, e.g., SVG element comprised 
a DOM tree of elements maintained in a separate file, then 
the next W3C command in the mixed statement program 
would likely be a command to set a SRC (source) attribute 
for the newly created clement specifying the URL of the 
separate file, e.g., the SVG file. W3C SVG commands in the 
mixed statement program can then be used to manipulate, 
add or modify elements maintained in the SVG file provid- 
ing the SVG DOM. Alternatively, the new embedded ele- 
ment may not have a corresponding file. In such case, the 
mixed statement programs may include W3C API state- 
ments to manipulate, add and modify further subnodes of the 
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node created for ihe embedded element in the DOM tree. In different user interface programs. This allows the bridge to 
this way, a file implementing the DOM of another user manipulate the DOM, including components of well known 
interface, e.g., SVG, may be embedded in the DOM of the user interface programs, such as a browser, as well as 
primary program, e.g., Internet Explorer. Further a new components of plug-in programs. Manipulation of these 
embedded SVG element, which may comprises an entire 5 DOM objects would then cause the corresponding layout 
SVG DOM file, may be attached to any node within the main ^.^gine to modify the displayed user interface in accordance 
Internet Explorer DOM tree at a location in the user interface changes to the manipulated DOM objects. 
(UI) DOM tree where the 20 SVG component is imple- 
mented. If the SVG component is implemented in an HTML Alternative Embodiments and Conclusions 
frame, then the SVG element implementing that SVG com- m ^ r 1. • . 1. i_ j- . 
ponent would be attached as a child node to the HTML ^ ^h^ foUowuig describes some altemaUve embodiments 
frame of which it is a part in the main browser interface. accomplishing the present mvention. 

If the element to create is not an embedded clement (at preferred embodiments may be implemented as a 

block 466), then the stub factory 208a, b determines (at ^^^''^^ apparatus or program using standard programming 

block 476) from the API mappings 204a. b the user interface f^/or engineering techniques to produce software, 

(UI) API to create an element. Hie stub factory 208a, b then firmware, hardware, or any combination thereof. Hie code 

calls (at block 478) the determined user interface (UI) API and mstructions m which the preferred embodiments are 

for the createEIement method to create an element having implemented are accessible from and embedded in an infor- 

the tagName as a node name. The stub factory 208a, b then '"^tion bearing niedium, which may comprise one or more 

receives (at block 480) the returned new user interface (UI) computer-readable devices firmware progr^^^^ 

element. Tlie stub factory 208 crates (at block 482) a Java memory devices (e.g., EEPROMs, ROMs, PROMs, RAMs, 

element for the returned new user interface (UI) element and SRAMs, etc.), hardware, electronic devices, a computer 

creates node pointer info from the Java element to the readable magnetic storage unit, CD-ROM, a file server 

returned user interface (UI) implementation of that Java providing access to the programs via a network transmission 

element. This new Java elemem for the newly created user 1^°^, wireless transmission media, signals propagating 

interface (UI) element is then returned (at block 484) to the through space, radio waves infrared signals, etc. Of course, 

bridge 200. The mixed statement program may then provide those skilled in the art will recognize that many modifica- 

a W3C API to append the new element to a location in the ^^^e to this configuration without departing 

user interface (UI) document object, or HTML DOM tree. ^^om the scope of the present invention. 

FIG. 9 illustrates logic implemented into the bridge 200 30 preferred implementations, the W3C API interfaces are 

when receiving a pointer to a user interface (UI) embedded provided and mapped to corresponding API mterfaces in the 

element at block 500. At block 502, the bridge 200 passes interface in which the mixed statement program will 

the pointer to the user interface (UI) embedded element to However, alternative embodiments may allow the 

stub factory in one kit i, e.g., stub factor 208a in kit 202a. use of standard API mterfaces other than W3C, For instance, 

The stub factory 208a, b determines (at block 504) if the 35 if another set of API interfaces, not those proposed by W3C, 

response received indicates that the stub factory does not ^ adopted industry wide, then the Bridge may provide 

support the user interface (UQ object This may be deter- mappings from those alternative industry standard API mter- 

mined using the query Interface API when the user interface ^aces to the implementation of those standard APIs in a 

program is Internet Explorer. If the stub factory does not ^^^^""^ operating system or web browser. In this way, the 

support the user interface (UI) embedded element, then the 40 P'^^°* mvention for mapping standard mterfaces may apply 

bridge 200 determines (at block 506) whether there are to allow the Java developer to utilize the API interface 

further kits 202a, b to consider. If so, then control proceeds standards to access non-Java components in the operating 

through block 508 to consider another kit. Otherwise, if system. 

there are no further kits, then an error message is returned to In preferred embodiments, the mixed statement programs 

the bridge 200, If a Java object is returned (at block 512) to 45 include Java programming language statements, which are 

the bridge 200, then the bridge 200 returns the Java object capable of being implemented on different operating system 

to the executing mixed statement program. platforms. In further embodiments, the mixed statement 

Once the user interface (UI) document object 226 is programs may include code from other computer languages 
manipulated by the APIs from the different user interface as well as alternative cross-platform languages other than 
programs, then the layout engines 224a, b for the different 50 Java. In such case, the preferred embodiments provide a 
user interface programs would update the display based on methodology for extending standard API interfaces to pro- 
changes to the nodes implementing the corresponding user grams to aUow the developer to utilize the standard API 
interface program. For instance, if the Internet Explorer interfaces to enhance the capabilities of the program and 
nodes of the DOM object were manipulated, then the program language being used. With preferred embodiments, 
Internet Explorer layout engine would generate native opcr- ss the programmer may write one application program or 
ating system commands to alter the display based on the mixed statement program including code m the cross- 
manipulation of the DOM nodes; or if the SVG nodes were platform computer language and include the industry stan- 
manipulated, then the SVG layout engine would generate dard API mterfaces, and then use implementations of the 
native operating system commands ^^^^^ to allow the program to execute on different operating 

With the preferred embodiment architecture, the bridge 60 ^y^tem through the browser layout engine, 

may handle W3C APIs calling Java objects associated with Preferred embodiments described the user interface as a 

different types of underlying user interface (UI) objects, i.e., graphical user interface, such as a web browser. However, 

Internet Explorer COM objects, SVG COM objects, etc, ihe user interface may be in any human observable format, 

This is accomplished by embedding a DOM tree for a such as voice interface, wherein the code in the mixed 

plug-in program as an element in the main user interface 65 statement program generates voice commands. 

DOM tree. The bridge 200 would then include the capability In non-Java implementations, a virtual machine program 

to map W3C APIs to user interface program APIs for may be provided to translate the application program to code 
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thai is independent of the operating system platform, and 
then transform the operating system independent bytecodes 
to native operating system object code. 

The bridge may be implemented in a JDK kit including 
the Java virtual machine. Alternatively, the bridge may be 5 
embedded into a ROM or flash memory. 

Preferred embodiments described the bridge mapping 
W3C API interfaces to corresponding interfaces in Mozilla 
browsers and the Microsoft Internet Explorer 5. However, 
there may be further implementations of the bridge to 
provide API for any browser that implements aspects of the 
W3C DOM standard, including DOM level 1, all of the 
W3C HTML 4.0, and parts of the DOM level 2, including 
the CORE, HTML, Events, StyleSheets, and Cascading 
Style Sheets. 

Preferred embodiments were described with respect to 
using the W3C API interfaces to access user interface 
objects, such as COM and XPCOM objects, which is the 
format of component objects in the Internet Explorer and 
Mozilla browser user interfaces, respectively. However, the 
bridge may map the W3C API interfaces to interfaces in any 
supported user interface program to access the objects in the 
format for that user interface. For instance, the bridge 4 may 
be used to interface with objects in the IBM System Object 
Model (SOM) format. 

Mixed statement programs may be executed on any 
computing device that is capable of executing the bridge to 
transform the mixed statement code to cither the native 
operating system code used by the computing device or the 
user interface APIs 12 and objects 14. 3Q 

The preferred algorithm described particular steps as 
occurring in a particular order However, in further embodi- 
ments the order of the steps may be changed and certain 
steps removed and added without departing from the scope 
of the invention. Moreover, different steps may be per- 35 
formed to execute the overall operation of the algorithm. 

In summary, the present invention provides a system, 
method, and program for for implementing components of a 
user interface as an object. A user interface is implemented 
in a first user interface program object including elements 40 
compatible with a first user interface program. A standard 
application program interface (API) calling a first standard 
object to create a second standard object as an element of the 
first standard object is received. The standard API is a 
member of a set of standard APIs, such as the W3C APIs. A 45 
second user interface program API is generated to create a 
second user interface program object corresponding to the 
second standard object. The second user interface program 
object is embedded as an element in the first user interface 
program object. 50 

The foregoing description of the preferred embodiments 
of the invention has been presented for the purposes of 
illustration and description. It is not intended to be exhaus- 
tive or to limit the invention to the precise form disclosed. 
Many modifications and variations are possible in light of 55 
the above teaching. It is intended that the scope of the 
invention be limited not by this detailed description, but 
rather by the claims appended hereto. The above 
specification, examples and data provide a complete descrip- 
tion of the manufacture and use of the composition of the 60 
invention. Since many embodiments of the invention can be 
made without departing from the spirit and scope of the 
invention, the invention resides in the claims hereinafter 
appended. 

What LS claimed is: 65 
1. A method for implementing components of a user 
interface as an object, comprising: 



implementing a user interface in a first user interface 
program object including elements compatible with a 
first user interface program; 

receiving a standard application program interface (API) 
calling a first standard object, wherein the standard API 
is a member of a set of standard APIs, to create a second 
standard object as an clement of the first standard 
object; 

generating a second user interface program API to create 
a second user interface program object corresponding 
to the second standard object; and 

embedding the second user interface program object as an 
element in the first user interface program object. 

2. The method of claim 1, further comprising: 
associating the second standard object and the second user 

interface program object; and 
returning the second standard object to a program includ- 
ing standard API calls to the second standard object. 

3. The method of claim 1, wherein a first stub factory 
provides a mapping of standard APIs to first user interface 
program APIs and standard objects to first user interface 
program objects and a second stub factory provides a 
mapping of standard APIs to second user interface program 
APIs and standard objects to second user interface program 
objects, wherein the first stub factory generates the second 
user interface program API to create the second user inter- 
face program object, and wherein the second stub factory 
associates the second standard object and the second user 
interface program object. 

4. The method of claim 1, further comprising: 
receiving a further standard (API) calling one standard 

object that is an element of the first or second user 

interface program objects; 
determining one first or second user interface program 

element implementing the called standard object; 
determining one first or second user interface program 

API that implements the received standard API; 
generating the determined first or second user interface 

program API calling the determined first or second user 

interface program element to manipulate the element in 

the first or second user interface program objects and 

affect a display of the user interface. 

5. The method of claim 4, wherein a first stub factory 
provides a mapping of standard APIs to first user interface 
program APIs and standard objects to first user interface 
program objects and a second stub factory provides a 
mapping of standard APIs to second user interface program 
APIs and standard objects to second user interface program 
objects, further comprising: 

determining one of the first and second stub factories 
capable of determining and generating the user inter- 
face program API calling the determined user interface 
program element. 

6. The method of claim S, wherein determining one of the 
first and second stub factories capable of determining and 
generating the user interface program API calling the deter- 
mined user interface program element comprises: 

sending the determined first or second user interface 
program element to the first stub factory; 

querying, with the first stub factory, the received user 
interface program element; 

receiving, with the first stub factory, return information in 
response to the query indicating whether the queried 
user interface program element is one first user inter- 
face program element, wherein the first stub factory 
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performs the steps of determining and generating one 
first user interface program API calling the determined 
first user interface program element if the response 
indicates that the received user interface element is one 
first user interface program clement; 

sending the determined first or second user interface 
clement to the second stub factory if the response to the 
query from the first stub factory indicates that the 
received user interface program element is not one first 
user interface program element; 

querying, with the second stub factory, the received user 
interface program element; and 

receiving, with the second stub factory, return information 
in response to the query indicating whether the received 
user interface program element is one second user 
interface program element, wherein the second stub 
factory performs the steps of determining and gener- 
ating one second user interface program API calling the 
determined second user interface program element if 
the response indicates that the received user interface 
program element is one second user interface program 
element. 

7. The method of claim 1, further comprising: 
receiving a further standard (API) calling one standard 

object that corresponds to one of the first or second user 

interface objects to create an additional element having 

a new element name; 
determining one first or second user interface object that 

implements the standard object; 
determining one first or second user interface program 

API to create one element; 
generating the determined first or second user interface 

program API calling the determined first or second user 

interface object to create an additional element having 

the new element name; and 
receiving one first or second user interface element having 

the element name. 

8. The method of claim 7, wherein a first stub factory 
provides a mapping of standard APIs to first user interface 
program APIs and first standard objects to first user interface 
objects and a second stub factory provides a mapping of 
standard APIs to second user interface program APIs and 
second standard objects to second user interface objects, 
further comprising: 

determining one of the first and second stub factories 
capable of determining and generating the user inter- 
face program API calling the determined first or second 
user interface object. 

9. The method of claim 7, further comprising appending 
the received element to one of the first or second user 
interface program objects. 

10. The method of claim 1, wherein the first user interface 
program comprises a browser program and wherein the 
second user interface program comprises a plug-in program 
to the browser program. 

11. The method of claim 1, wherein the set of standard 
APIs comprises the W3C DOM APIs, and wherein the first 
and second user interface programs implement the W3C 
DOM. 

12. The method of claim 1, wherein the second user 
interface object comprises a file including further second 
user interface sub-element objects. 

13. A system for implementing components of a user 
interface as an object, comprising: 

means for implementing a user interface in a first user 
interface program object including elements compat- 
ible with a first user interface program; 
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means for receiving a standard application program inter- 
face (API) calling a first standard object, wherein the 
standard API is a member of a set of standard APIs, to 
create a second standard object as an element of the first 
standard object; 

means for generating a second user interface program API 
lo create a second user interface program object cor- 
responding to the second standard object; and 

means for embedding the second user interface program 
object as an element in the first user interface program 
object. 

14. TTie system of claim 13, further comprising: means for 
associating the second standard object and the second user 
interface program object; and 

means for returning the second standard object to a 
program including standard API calls to the second 
standard object. 

15. The system of claim 13, wherein a first stub factory 
provides a mapping of standard APIs to first user interface 
program APIs and standard objects to first user interface 
program objects and a second stub factory provides a 
mapping of standard APIs to second user interface program 
APIs and standard objects to second user interface program 
objects, wherein the first stub factory comprises the means 
for generating the second user interface program API to 
create the second user interface program object, and wherein 
the second stub factory comprises the means for associating 
the second standard object and the second user interface 
program object. 

16. The system of claim 13, further comprising: 
means for receiving a further standard (API) calling one 

standard object that is an element of the first or second 
user interface program objects; 
means for determining one first or second user interface 
program element implementing the called standard 
object; 

means for determining one first or second user interface 
program API that implements the received standard 
API; 

means for generating the determined first or second user 
interface program API calling the detenmined first or 
second user interface program element to manipulate 
the element in the first or second user interface program 
objects and affect a display of the user interface. 

17. The system of claim 16, wherein a first stub factory 
provides a mapping of standard APIs to first user interface 
program APIs and standard objects to first user interface 
program objects and a second stub factory provides a 
mapping of standard APIs to second user interface program 
APIs and standard objects to second user interface program 
objects, further comprising: 

means for determining one of the first and second stub 
factories capable of determining and generating the 
user interface program API calling the determined user 
interface program element. 

18. The system of claim 17, wherein the means for 
determining one of the first and second stub factories 
capable of determining and generating the user interface 
program API calling the determined user interface program 
element comprises: 

sending the determined first or second user interface 
program clement to the first stub factory; 

querying, with the first stub factory, the received user 
interface program element; 

receiving, with the first stub factory, return information in 
response to the query indicating whether the queried 
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user interface program element is one first user inter- 
face program element, wherein the first stub factory 
performs the steps of determining and generating one 
first user interface program API calling the determined 
first user interface program element if the response 
indicates that the received user interface element is one 
first user interface program element; 

sending the determined first or second user interface 
element to the second stub factory if the response to the 
query from the first stub factory indicates that the 
received user interface program element is not one first 
user interface program element; 

querying, with the second stub factory, the received user 
interface program element; and 

receiving, with the second stub factory, return information 
in response to the query indicating whether the received 
user interface program element is one second user 
interface program clement, wherein the second stub 
factory performs the steps of determining and gener- 
ating one second user interface program API calling the 
determined second user interface program element if 
the response indicates that the received user interface 
program element is one second user interface program 
element. 

19. The system of claim 13, further comprising: 
means for receiving a further standard (API) catling one 

standard object that corresponds to one of the first or 
second user interface objects to create an additional 
element having a new element name; 

means for determining one first or second user interface 
object that implements the standard object; 

means for determining one first or second user interface 
program API to create one clement; 

means for generating the determined first or second user 
interface program API calUng the determined first or 
second user interface object to create an additional 
element having the new element name; and 

means for receiving one first or second user interface 
element having the element name. 

20. The system of claim 19, wherein a first stub factory 
provides a mapping of standard APIs to first user interface 
program APIs and first standard objects to first user interface 
objects and a second stub factory provides a mapping of 
standard APIs to second user interface program APIs and 
second standard objects to second user interface objects, 
further comprising: 

means for determining one of the first and second stub 
factories capable of determining and generating the 
user interface program API calling the determined first 
or second user interface object. 

21. The system of claim 19, further comprising means for 
appending the received element to one of the first or second 
user interface program objects. 

22. The system of claim 13, wherein the first user inter- 
face program comprises a browser program and wherein the 
second user interface program comprises a plug-in program 
to the browser program. 

23. The system of claim 13, wherein the set of standard 
APIs comprises the W3C DOM APIs, and wherein the first 
and second user interface programs implement the W3C 
DOM. 

24. The system of claim 13, wherein the second user 
interface object comprises a file including further second 
user interface sub-element objects. 

25. An information bearing medium including code for 
implementing components of a user interface as an object, 
wherein the code is capable of causing a processor to 
perform: 
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implementing a user interface in a first user interface 
program object including elements compatible with a 
first user interface program; 

receiving a standard application program interface (API) 
calling a first standard object, wherein the standard API 
is a member of a set of standard APIs, to create a second 
standard object as an element of the first standard 
object; 

generating a second user interface program API to create 
a second user interface program object corresponding 
to the second standard object; and 

embedding the second user interface program object as an 
clement in the first user interface program object. 

26. The information bearing medium of claim 25, wherein 
the code is further capable of causing the processor to 
perform: 

associating the second standard object and the second user 
interface program object; and 

returning the second standard object to a program includ- 
ing standard API calls to the second standard object. 

27. The information bearing medium of claim 25, wherein 
a first stub factory provides a mapping of standard APIs to 
first user interface program APIs and standard objects to first 
user interface program objects and a second stub factory 
provides a mapping of standard APIs to second user inter- 
face program APIs and standard objects to second user 
interface program objects, wherein the first stub factory 
generates the second user interface program API to create 
the second user interface program object, and wherein the 
second stub factory associates the second standard object 
and the second user interface program object. 

28. The information bearing medium of claim 25, wherein 
the code is further capable of causing the processor to 
perform: 

receiving a further standard (API) calling one standard 
object that is an element of the first or second user 
interface program objects; 

determining one first or second user interface program 
element implementing the called standard object; 

determining one first or second user interface program 
API that implements the received standard API; 

generating the determined first or second user interface 
program API calling the determined first or second user 
interface program element to manipulate the element in 
the first or second user interface program objects and 
affect a display of the user interface. 

29. The information bearing medium of claim 28, wherein 
a first stub factory provides a mapping of standard APIs to 
first user interface program APIs and standard objects to first 
user interface program objects and a second stub factory 
provides a mapping of standard APIs to second user inter- 
face program APIs and standard objects to second user 
interface program objects, further comprising: 

determining one of the first and second stub factories 
capable of determining and generating the user inter- 
face program API calling the determined user interface 
program element. 

30. The information bearing medium of claim 29, wherein 
determining one of the first and second stub factories 
capable of determining and generating the user interface 
program API calling the determined user interface program 
element comprises: 

sending the determined first or second user interface 
program element to the first stub factory; 

querying, with the first stub factory, the received user 
interface program element; 
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receiving, with the first stub factory, return information in 
response to the query indicating whether the queried 
user interface program element is one first user inter- 
face program element, wherein the first stub factory 
performs the steps of determining and generating one s 
first user interface program API calling the determined 
first user interface program element if the response 
indicates that the received user interface element is one 
first user interface program element; 

sending the determined first or second user interface 
element to the second stub factory if the response to the 
query from the first stub factory indicates that the 
received user interface program element is not one first 
user interface program element; 

querying, with the second stub factory, the received user 
interface program element; and 

receiving, with the second stub factory, return information 
in response to the query indicating whether the received 
user interface program element is one second user 
interface program element, wherein the second stub 
factory performs the steps of determining and gener- 
ating one second user interface program API calling the 
determined second user interface program element if 
the response indicates that the received user interface 
program element is one second user interface program 
element. 

31. The information bearing medium of claim 25, wherein 
the code is further capable of causing the processor to 
perform: 3q 
receiving a further standard (API) calling one standard 
object that corresponds to one of the first or second user 
interface objects to create an additional element having 
a new element name; 
determining one first or second user interface object that 35 
implements the standard object; 
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determining one first or second user interface program 

API to create one element; 
generating the determined first or second user interface 

program API calling the determined first or second user 

interface object to create an additional element having 

the new element name; and 
receiving one first or second user interface element having 

the element name. 

32. The information bearing medium of claim 31, wherein 
a first stub factory provides a mapping of standard APIs to 
first user interface program APIs and first standard objects to 
first user interface objects and a second stub factory provides 
a mapping of standard APIs to second user interface pro- 
gram APIs and second standard objects to second user 
interface objects, further comprising: 

determining one of the first and second stub factories 
capable of determining and generating the user inter- 
face program API calling the determined first or second 
user interface object. 

33. The information bearing medium of claim 31, wherein 
the code is further capable of causing the processor to 
perform appending the received element to one of the first or 
second user interface program objects. 

34. The information bearing medium of claim 25, wherein 
the first user interface program comprises a browser pro- 
gram and wherein the second user interface program com- 
prises a plug- in program to the browser program. 

35. The information bearing medium of claim 25, wherein 
the set of standard APIs comprises the W3C DOM APIs, and 
wherein the first and second user interface programs imple- 
ment the W3C DOM, 

36. The information bearing medium of claim 25, wherein 
the second user interface object comprises a file including 
further second user interface sub-element objects, 

* ♦ ♦ ♦ ♦ 
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